fix(postgres): create content trigram index with fastupdate=off#606
fix(postgres): create content trigram index with fastupdate=off#606flexiondotorg wants to merge 2 commits into
Conversation
idx_messages_content_trgm is created with PostgreSQL's default fastupdate=on. The resulting GIN pending list is only merged into the index by VACUUM, so under continuous `pg sync` ingest where long-lived transactions pin the xmin horizon and starve autovacuum, it grows without bound. In one deployment the index bloated to 283 GB for ~213k rows and filled the disk, crashing PostgreSQL with ENOSPC. Disabling fastupdate merges entries directly into the tree, keeping the index bounded and predictable at a small per-insert cost.
roborev: Combined Review (
|
CREATE INDEX IF NOT EXISTS only applies WITH (fastupdate = off) on first creation, so stores upgraded from an earlier schema retained the default fastupdate=on. Reapply idempotently with ALTER INDEX on every schema bootstrap, and assert reloptions in the pgtest suite. Addresses review feedback on kenn-io#606.
roborev: Combined Review (
|
|
So whats the performance impact of this change? Since the alternate would be something like running |
Closes #605.
Adds
WITH (fastupdate = off)to theidx_messages_content_trgmcreation increateContentSearchIndexesPG, and reapplies it idempotently viaALTER INDEXon every schema bootstrap so stores upgraded from a schema that created the index with the defaultfastupdate=onare covered too. A pgtest assertion guardsreloptions. See #605 for the diagnosis and impact.Validation: recreating the index with
fastupdate=offreduced the same data from 283 GB to 388 MB.Existing over-sized indexes stop growing immediately; a one-time
REINDEXreclaims space already consumed.